1. Field of the Invention
The present invention relates to digital certificates in a PKI (Public Key Infrastructure). More particularly, the present invention relates to the automated tracking of a certificate pedigree of digital certificates in a PKI to enable a determination as to the trustworthiness of a digital certificate.
2. Description of the Related Art
A PKI is a set of policies, procedures, and software that permit an organization to generate, issue, and manage public/private cryptographic keys in a manner that allows users to reliably determine the identity of the owner of each public/private key pair. The key components of a PKI include: (1) a mechanism for reliably conveying the identity of a key pair's owner to the end user; (2) software applications for generating and managing key pairs that support this mechanism; (3) a set of procedures for generating and revoking key pairs that ensures that the identity of the owner can be reliably determined; and (4) a set of policies defining who may obtain public/private key pairs and identifying how each pair may be used.
As to component (1) of a PKI, most PKIs establish that the user owns a key pair by using an electronic document called a digital certificate. Digital certificates contain information identifying the owner of the key pair, the public component of the pair, and the period of time for which the certificate is valid. The digital certificate also identifies technical information about the key itself, such as the algorithm used to generate the key and the key length.
Certificates are generated by organizations that are responsible for verifying the identity of individuals, or in some instances, other organizations to which certificates are being issued. The identity of the certifying organization, referred to as a certificate authority, is recorded in each certificate, which is then signed using a private key known only to the certificate authority itself. This allows users to verify both the integrity of the certificate and the identity of the authority that issued it.
Certificate authorities generally employ any of a number of different commercially available software products to manage the creation, renewal, and revocation of certificates. These Certificate Management Systems (CMS) take information obtained through the user registration process, create a certificate, and sign it with the certificate authority's private key. The applicable CMS software maintains a database of all of the certificates that it has issued, and their statuses. The CMS is also responsible for revoking certificates, and for publishing a certificate revocation list that identifies the date on which each certificate was revoked, and the reason for the revocation. This information allows relying users (that is, those individuals or systems that are performing encryption or signature verification actions based on certificates) to review the status of a certificate, to assess its usability. A list of distribution points from which the CRL can be obtained are identified in the certificate itself.
In issuing a certificate, a certificate authority is stating that is has verified that the public key that appears in the certificate (and, by extension, the corresponding private key) belongs to the individual listed in the certificate. The integrity with which the registration process operates is therefore of great importance. The process must provide mechanisms for reliably identifying an individual and for verifying that the public key listed in the certificate belongs to that individual. Equally important, the certificate authority must provide procedures for revoking certificates in the event that the private key is compromised. A compromised private key calls into question the entire basis for trusting a certificate, since more than one individual may be using that private key to sign documents, or more than one individual may be able to decrypt documents encrypted using the corresponding public key.
Relying individuals and organizations must have a clear understanding of their certificate authority's operation processes. As a result, most certificate authorities publish a Certificate Practice Statement (CPS) that details the processes for registering users, issuing certificates, renewing certificates and revoking certificates. The CPS is normally published on the certificate authority's website.
Certificates often contain additional information that identifies an individual as a member of a particular organization and perhaps the role that they play in the organization. For example, the certificate may identify the certificate holder as being an employee of a company or a customer or subcontractor or supplier of the company. The policies determining who is eligible to hold a certificate are therefore important if individuals and organizations are to rely upon this information. These policies govern the overall operation of the certificate authority.
The policies under which users register for certificates determine the initial degree of trust that a relying party should place in a certificate. However, the manner in which the public key associated with the certificate is protected is equally as important. Private keys may be stored in any of several different ways. They may be placed on password protected public storage media, such as directories or databases. They may also be stored on password protected media accessible only to the certificate holder or to a relatively small number of persons, such as a floppy disk, the hard drive of the certificate holder's personal computer, or a portable storage device such as a smart card. A more secure storage medium is provided by hardware tokens containing encryption “engines.” These hardware tokens actually generate and store the private key and perform all encryption/decryption functions within the token. Hardware tokens typically require a password to activate and, since they remain in the possession of the certificate holder at all times, are substantially more secure than other storage media.
In a manual registration process, a human registration agent may ascertain the nature, or “pedigree,” of the storage media on which the certificate and its corresponding private key are stored. When the process of issuing a digital certificate is automated, there is no way of keeping track of the “pedigree” of the certificate which was generated. That is, was the certificate originally generated on a client PC or on a smart card or on a hardware token? The different categories of hardware computing devices are all capable of generating digital certificates which, from a software standard, are identical in format and content.
The pedigree of the digital certificate can have a significant bearing on the business functions to which that certificate is applied. That is, a certificate generated on a client PC will typically be less trustworthy than a certificate generated on a hardware token in that hardware tokens are typically more difficult for hackers to compromise than conventional PCs and hence certificates generated by such tokens have a higher level of trust. Accordingly, unless the PKI can keep track of the pedigree of the certificate, one may not know what level of trust to place on business functions associated with that certificate.
Unfortunately, earlier PKI registration processes provide no automated mechanism for tracking the pedigree of a certificate, that is, they provide no mechanism for keeping track of what kind of hardware was used to generate the private/public key pair. In cases where pedigree checking has been required, the tracking was performed manually. Manual tracking is expensive and time-consuming.